\chapter{Le mod\`ele de donn\'ees}
\label{chap:modele.donnee}
\minitoc

\section{Les \'etats}
La conception du mod\`ele de donn\'ee passe par une compr\'ehension approfondie des diff\'erents  \'etats d'une r\`egles et des notifications 
subjacentes.


%-------------------------------------%
\subsection{\'Etats-transition d'une r\`egle}
Le diagramme d'\'etat transition dans la figure \ref{fig:etat.transition.regle} met en exergue les diff\'erents \'etats d'une r\`egle. 
Une r\`egle est soit activ\'ee ou d\'esactiv\'ee. 
L'activation correspond \`a l'envoi de la r\`egle dans le moteur de r\`egle Drools. 

Lorsque l'utilisateur saisie une nouvelle r\`egle, celle-ci est par d\'efaut d\'esactiv\'ee. 
Pour l'activer, l'utilisateur envoie une requ\^ete 
d'activation et la r\`egle passe en mode activation demand\'ee. Si la demande se solde par un \'echec, la r\`egle reste dans cet \'etat. 
Si c'est par contre une r\'eussite, la r\`egle passe dans l'\'etat activ\'ee.

\begin{figure}
   \includegraphics[width=1.0\textwidth]{Modele_donnee/etat_transition_regle}
   \caption{\label{fig:etat.transition.regle}  \'Etats-transition d'une r\`egle}
\end{figure}



%-------------------------------------%
\subsection{\'Etats-transitions d'une notification}

Une notification est lanc\'ee par le moteur de r\`egle lorsque l'ensemble des conditions de celle-ci sont satisfaites. Son but est d'avertir 
l'administrateur syst\`eme. Notification Board, vu plus haut, est pr\'esent\'e sous forme de tableau contenant l'ensemble des notifications. 
La principale 
action propos\'ee est l'acquittement d'une notification et traduit le fait que la notification a \'et\'e trait\'ee par un utilisateur. 

\begin{figure}
   \includegraphics[width=0.6\textwidth]{Modele_donnee/etat_transition_notif}
   \caption{\label{fig:etat.transition.notif}  \'Etats-transition d'une notification}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Les \'ev\`enements associ\'es}
Les diff\'erentes r\`egles sont envoy\'ees dans le moteur de r\`egle Drools pour ex\'ecution. Lorsque l'ensemble des conditions d'une r\`egle est 
remplie, un 
\'ev\'enement particulier appel\'e \verb|JasmineEventNotification| est envoy\'e, ce dernier ayant pour but de signaler qu'une notification a \'et\'e 
\'emise et constitue 
la r\`egle de base.  Il poss\`ede  une  principale sp\'ecialisation, \`a savoir :
\begin{itemize}
 \item \verb|JasmineEventNotificationMail| : lev\'e lorsqu'un mail doit \^etre envoy\'e
 \item \verb|JasmineEventNotificationSNMP| : lev\'e pour l'envoi d'une trappe SNMP
\end{itemize}

De plus, une notification peut contenir des informations suppl\'ementaires n\'ecessaires \`a la bonne compr\'ehension de l'\'ev\`enement 
d\'eclencheur. 
Ces d\'etails sont mod\'elis\'es par \verb|JasmineEventNotificationDetail|.

Le diagramme de classes dans la figure \ref{fig:model.even} met en \oe uvre ces diff\'erents concepts, qui sont d\'evelopp\'es
dans le projet \verb|jasmine-event| : 
\begin{figure}
   \includegraphics[width=1.0\textwidth]{Modele_donnee/model_even}
   \caption{\label{fig:model.even}  Mod\'elisation des \'ev\`enements}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Persistance des notifications}
La persistance des notifications permet de r\'ecup\'erer les diff\'erentes notifications sur la console d'administration 
\`a partir d'une base de donn\'ees ou d'un topic JMS. 
Cette partie a \'et\'e int\'egr\'ee dans le projet EventSwitch  qui int\`egre Mule, nous permettant de cr\'eer des points d'entr\'e et de 
sortie. Un exemple 
r\'eel sera le cas o\`u une notification sera envoy\'ee par le moteur de r\`egle sur un topic JMS (point d'entr\'ee), 
Mule \'ecoutera sur ce point d'entr\'ee et 
chaque fois qu'il y aura une nouvelle notification, celle-ci sera persist\'ee en base de donn\'ees (point de sortie) .

%-------------------------------------%
\subsection{JasmineEventNotificationEBImpl}
\verb|JasmineEventNotificationEBImpl| est l'entity bean correspondant \`a une notification. Ses attributs sont les suivants :

\begin{description}
\item[id :] identifiant de la notification
\item[date :] date de d\'eclenchement de la notification
\item[level :] niveau d'alerte de la notification
\item[message :] message de description de la notification 
\item[status :] statut de la notification 
\end{description}

Par ailleurs, il contient plusieurs informations compl\'ementaires  persist\'ees aussi en base de donn\'ees \`a travers l'entity bean 
\verb|JasmineEventDetail| dont les attributs sont :
\begin{description}
\item[id :] identifiant du d\'etail
\item[key :] cl\'e de description
\item[value :] valeur correspondant \`a la cl\'e
\end{description}

%-------------------------------------%
\subsection{JasmineEventNotificationSLBRemote}
L'interface \verb|JasmineEventNotificationSLBRemote| d\'ecrit les actions possibles permettant la manipulation de ces beans. Elle est 
impl\'ement\'ee 
par \verb|JasmineEventNotificationSLBImpl| qui poss\`ede deux m\'ethodes :

\begin{itemize}
\item \verb|saveEvent(ev:JasmineEventNotification)|
 permet la sauvegarde d'une notification
\item \verb|getEvents(int id, String level, Sting message, status Boolean)| permet la r\'ecup\'eration d'un ensemble de notification en fonction 
de crit\`eres.
\end{itemize}

Le diagramme de classe dans la figure \ref{fig:model.persistance} met en \oe uvre les diff\'erentes classes n\'ecessaires \`a la persistance :
\begin{landscape}
\begin{figure}
   \includegraphics[width=1.2\textwidth]{Modele_donnee/model_persistance}
   \caption{\label{fig:model.persistance}  Mod\'elisation de persistance d'un \'ev\'enement}
\end{figure}
\end{landscape}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{L'envoie des notifications}
Comment \`a partir d'une r\`egle allons nous envoyer nos diff\'erentes notifications ? 
Pour cela nous avons cr\'e\'e un client utilisable dans une r\`egle. Ce 
client consiste \`a r\'ecup\'erer l'instance de Mule lanc\'ee. En suite, on lui passe l'URI 
o\`u les diff\'erentes notifications seront envoy\'ees, en v\'erifiant au pr\'ealable que Mule 
poss\`ede un point d'entr\'ee sur cette URI. Ces actions sont assez simples \`a r\'ealiser car 
Mule fournit une API compl\`ete et bien document\'ee.

Pour cette partie, le projet \verb|jasmine-monitoring-notification| est la base du travail et 
fournie un ensemble de librairies utilisables par plusieurs 
projets de monitoring. Le client pouvant servir dans d'autres projets, ce projet a donc 
\'et\'e choisi comme support. Il utilise cependant plusieurs classes provenant de l'EventSwitch.

%-------------------------------------%
\subsection{NotificationEventDispatcher}
\verb|NotificationEventDispatcher| est le client utilis\'e pour envoyer les notifications. 
Pour cela, il dispose d'une m\'ethode statique qui prend en 
param\`etre une notification (\verb|JasmineEventNotification|) et une URI. 
Il positionne ensuite le contexte et le processeur d'envoi  \`a travers 
\verb|JasmineEventNotificationDispatcher| et \verb|DispatcherContext|. 
La m\'ethode \verb|dispatchEvent| de \verb|JasmineEventNotificationDispatcher| est utilis\'ee pour envoyer 
la notification.
\begin{figure}
   \includegraphics[width=0.9\textwidth]{Modele_donnee/enchaine_syst}
   \caption{\label{fig:enchaine.syst} Diff\'erentes \'etapes d'encha\^inement du syst\`eme}
\end{figure}

\begin{landscape}
\begin{figure}
   \includegraphics[width=1.2\textwidth]{Modele_donnee/model_envoie_notif}
   \caption{\label{fig:model.envoie.notif}  Mod\`ele d'envoi d'une notification}
\end{figure}
\end{landscape}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{La gestion des r\`egles}
\subsection{Repr\'esentation}
Toute r\`egle appartient \`a un package bien pr\'ecis qui est repr\'esent\'e au 
plus bas niveau par l'interface \verb|IRulePackage|. Il poss\`ede deux extensions :
\verb|ITextualRulePackage| repr\'esentant une r\`egle textuelle (\'ecrite \`a la main) et
\verb|IVisualRulePackage| repr\'esentant une r\`egle \'edit\'ee graphiquement.

\verb|TextualRulePackage| et \verb|VisualRulePackages| repr\'esentent les
classes concr\`etes associ\'ees \`a ces deux interfa\c{c}es et \'etendent 
chacunes la classe abstraite englobante \verb|AbstractRulePackage| qui impl\'emente
\`a son tour \verb|IRulePackage|.

Chaque r\`egle visuelle est compos\'ee d'un ensemble de r\`egles (\verb|IRules|), 
chacune est mise en \oe uvre par la classe concr\`ete \verb|Rule|. Une r\`egle donn\'ee est 
compos\'ee d'une partie WHEN (\verb|ILHSElement|) et d'une partie THEN (\verb|IRHSElement|).

Le mod\`ele ci dessous montre comment ins\'erer pour chacune des parties de la 
r\`egle un code correspodant. \verb|LHSCodeSnippet| impl\'emente alors un \verb|ILHSElement| et
\verb|RHSCodeSnippet| un \verb|IRHSElement|.

Le sch\'ema \ref{fig:modele.regle} montre le mod\`ele de description des r\`egles.

\begin{figure}
   \includegraphics[width=1.1\textwidth]{Modele_donnee/modele_po}
   \caption{\label{fig:modele.regle} Mod\`ele de description des r\`egles}
\end{figure}

\subsection{Persistance}
La persistance des r\`egles permet de r\'ecup\'erer les diff\'erentes r\`egles sur la console d'administration \`a partir d'une base de donn\'ees. Il sera ainsi possible de sauvegarder une r\`egle puis de retrouver son \'etat en cas de red\'emarrage du serveur.
Le mod\`ele de persistance est calqu\'ee sur le mod\`ele pr\'ec\'edant en introduisant les Entity Bean. \verb|RuleengineManagerBundle| est un service OSGI permettant de d\'emarrer le manager des r\`egles. \verb|RulePackageSLBRemote| correspond \`a l'interface remote et d\'ecrit les diff\'erentes actions applicables aux Entity Beans. 
Le sch\'ema \ref{fig:modele.persist} montre le mod\`ele de persistance des r\`egles.
\begin{figure}
   \includegraphics[width=1.1\textwidth]{Modele_donnee/modele_pojo}
   \caption{\label{fig:modele.persist} Mod\`ele de persistance des r\`egles}
\end{figure}


%end Modele_donnees.tex
